7.07. Шифрование

В РАЗРАБОТКЕНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНО

Разработчику Инженеру

Шифрование

Шифрование представляет собой один из фундаментальных механизмов обеспечения информационной безопасности. Его суть заключается в целенаправленном и обратимом преобразовании данных таким образом, что результирующий шифротекст становится нечитаемым для любого субъекта, не обладающего соответствующими полномочиями. Обратимость преобразования означает, что при наличии корректного ключа и знания алгоритма исходная информация может быть восстановлена без потерь.

Шифрование — это системная инженерная практика, встроенная в архитектуру современных информационных систем на всех уровнях: от сетевого взаимодействия и хранения файлов до аутентификации пользователей и верификации программного кода. Цель шифрования — реализация трёх базовых свойств информационной безопасности: конфиденциальности, целостности и аутентичности. Ни одно из этих свойств не может быть полноценно обеспечено без криптографических методов.

Конфиденциальность

Конфиденциальность означает, что данные доступны только тем, кому это разрешено. Шифрование реализует это свойство, ограничивая возможность чтения информации: даже при физическом доступе к носителю (жёсткому диску, перехваченному сетевому пакету, резервной копии в облаке) постороннее лицо не может интерпретировать содержимое без знания ключа.

На практике это выглядит следующим образом: перед передачей или сохранением данные поступают на вход алгоритма шифрования вместе с криптографическим ключом. Алгоритм, выполняя последовательность детерминированных операций, порождает выходной поток байтов — шифротекст, статистически неотличимый от случайного шума. Только обладатель того же (для симметричных схем) или соответствующего (для асимметричных) ключа способен инициировать обратное преобразование — расшифрование — и получить исходные данные. При этом отсутствие ключа принципиально исключает возможность восстановления оригинала, если только не нарушено одно из условий: криптостойкость алгоритма, безопасность генерации или хранения ключа, корректность реализации протокола.

Целостность и аутентичность

С развитием цифровых систем шифрование стало применяться не только для сокрытия содержания. Оно интегрировалось в механизмы контроля целостности — гарантии того, что данные не были изменены в процессе хранения или передачи. Это достигается с помощью криптографических хэш-функций и кодов аутентификации сообщений (например, HMAC), которые генерируют уникальные «отпечатки» данных. Любое изменение — даже одного бита — приводит к радикальному изменению хэша, что позволяет обнаружить подмену.

Аутентичность — свойство, подтверждающее происхождение данных и идентичность отправителя. Здесь ключевую роль играют цифровые подписи и протоколы на основе асимметричной криптографии. Подпись, созданная с использованием приватного ключа, может быть проверена любым обладателем соответствующего публичного ключа, но подделать её без доступа к приватному ключу вычислительно невозможно. Это даёт юридическую и техническую неотказуемость: субъект, подписавший документ, не может впоследствии отрицать своё участие.

Таким образом, современное понимание шифрования выходит за рамки простого сокрытия. Оно представляет собой набор математически обоснованных протоколов, обеспечивающих комплексную защиту информации в условиях потенциально враждебной среды.

Исторический контекст

История шифрования насчитывает тысячелетия. Самые ранние известные примеры датируются Древним Египтом и Месопотамией и включали примитивные методы замены символов — так называемые шифры подстановки. В классической античности получили распространение шифры сдвига, такие как шифр Цезаря, где каждая буква алфавита смещалась на фиксированное число позиций. Несмотря на простоту, такие методы демонстрировали ключевую идею: секретность зависит не от алгоритма (который часто был общеизвестен), а от параметра — ключа.

Средневековье и эпоха Возрождения принесли развитие многоалфавитных шифров, таких как шифр Виженера, существенно повышавших стойкость за счёт использования нескольких последовательных подстановок. Однако лишь с появлением механических устройств — в первую очередь, немецкой шифровальной машины «Энигма» в XX веке — криптография перешла в промышленную фазу. «Энигма» использовала роторную систему, многократно переставлявшую алфавит при каждом нажатии клавиши, что теоретически обеспечивало огромное пространство ключей. Тем не менее, её взлом союзниками в Блетчли-Парке стал возможен благодаря комбинации математического анализа (работы Аланом Тьюрингом), эксплуатации процедурных ошибок операторов и использования первых электромеханических вычислителей.

Этот этап подтвердил два принципа, актуальных и сегодня:
— стойкость системы зависит от алгоритма и от дисциплины его применения;
— вычислительная мощность является критическим фактором в оценке криптостойкости.

Цифровая революция 1960–1970-х годов потребовала перехода от механических и бумажных методов к программным и аппаратным. Появление первых стандартов — таких как DES (Data Encryption Standard) в 1977 году — ознаменовало формирование шифрования как инженерной дисциплины. DES, несмотря на короткую длину ключа (56 бит), стал основой для массового внедрения криптографии в банковские и военные системы. Его последующая замена на AES (Advanced Encryption Standard) в 2001 году отразила рост вычислительных возможностей и необходимость поддержки более длинных ключей (128, 192, 256 бит).

Однако настоящий прорыв произошёл в 1976 году, когда Уитфилд Диффи и Мартин Хеллман опубликовали работу «New Directions in Cryptography». В ней была предложена концепция асимметричной криптографии, или криптографии с открытым ключом. Эта идея разрешила главную проблему симметричных систем — безопасный обмен ключами между сторонами, не имеющими предварительного доверия. Вместо одного секретного ключа предлагалось использовать пару математически связанных ключей: открытый (публичный), который можно свободно распространять, и закрытый (приватный), который хранится в секрете. Шифрование с публичным ключом не позволяет расшифровать сообщение — только зашифровать; расшифрование возможно исключительно с помощью приватного ключа.

Это открытие стало основой для всей современной инфраструктуры доверия: SSL/TLS для защищённого веба, PGP для электронной почты, цифровых сертификатов, блокчейнов и защищённых мессенджеров. Оно также позволило реализовать цифровые подписи — механизм, в котором приватный ключ используется для создания криптографической «печати», проверяемой с помощью публичного ключа.

Ключ

Если алгоритм шифрования можно рассматривать как «замок», то ключ — это «ключ от замка». Именно ключ определяет, какое конкретное преобразование будет применено к данным. Один и тот же алгоритм при разных ключах порождает совершенно разные шифротексты, даже если входные данные идентичны.

Стойкость любой криптосистемы в конечном счёте сводится к трём компонентам:

1. Криптографическая стойкость алгоритма — его устойчивость к математическому анализу и вычислительным атакам (в том числе перебору);
2. Длина и энтропия ключа — количество возможных значений ключа и отсутствие предсказуемости в его генерации;
3. Операционная безопасность — процедуры хранения, передачи, использования и уничтожения ключей.

Из этих трёх компонентов именно третий чаще всего становится слабым звеном. Алгоритмы вроде AES-256 или ChaCha20-Poly1305 считаются вычислительно неуязвимыми даже для гипотетических квантовых компьютеров на сегодняшний день. Однако если ключ будет сгенерирован на основе слабого источника энтропии (например, текущего времени с точностью до секунды), сохранён в открытом текстовом файле, передан по незащищённому каналу или введён пользователем в виде «password123», вся система теряет смысл.

Поэтому управление ключами (Key Management) выделяется как отдельная, критически важная дисциплина. Она включает в себя:
— генерацию ключей с использованием криптографически стойких генераторов случайных чисел (CSPRNG);
— безопасное хранение (в защищённых модулях, таких как HSM — Hardware Security Module, или в зашифрованных контейнерах с доступом по многофакторной аутентификации);
— распределение (с использованием защищённых протоколов, например, Diffie–Hellman для установления общего секрета);
— ротацию (плановую замену ключей через определённый интервал или при подозрении на компрометацию);
— уничтожение (гарантированное стирание ключей после окончания срока действия или сессии).

Особое внимание уделяется сеансовым ключам — временным ключам, используемым только в рамках одного сеанса связи (например, одного HTTPS-соединения). После завершения сессии такой ключ уничтожается, что реализует свойство Perfect Forward Secrecy (PFS): даже если долгосрочный приватный ключ будет скомпрометирован в будущем, ранее перехваченные сессии останутся защищёнными, поскольку для их расшифровки требовался временный сеансовый ключ, уже не существующий.

Алгоритмы шифрования

Современные алгоритмы симметричного шифрования делятся на два больших класса: блочные шифры и поточные шифры.

Блочные шифры обрабатывают данные фиксированными порциями — блоками. Например, AES работает с блоками по 128 бит (16 байт), независимо от длины исходного сообщения. Если сообщение короче блока, применяется дополнение (padding); если длиннее — используется режим работы (mode of operation), определяющий, как шифровать последовательность блоков. Наиболее распространённые режимы — CBC (Cipher Block Chaining), GCM (Galois/Counter Mode), CTR (Counter Mode). Режим GCM, например, обеспечивает шифрование и аутентификацию данных (Authenticated Encryption with Associated Data, AEAD), объединяя конфиденциальность и целостность в одном механизме.

Поточные шифры, напротив, генерируют бесконечный (в теоретическом смысле) поток псевдослучайных битов — ключевой поток — который побитово накладывается (обычно посредством XOR) на открытый текст. Это позволяет шифровать данные по мере их поступления, без необходимости буферизации целого блока. Такой подход особенно эффективен для потоковых данных: аудио-, видеотрансляций, сетевых сокетов в реальном времени. Яркий пример — шифр ChaCha20, разработанный Дэниелом Бернштейном как альтернатива RC4 (который оказался уязвим) и активно используемый сегодня в TLS 1.3 и мобильных приложениях благодаря высокой скорости и устойчивости к side-channel атакам.

Выбор между блочным и поточным шифром определяется характеристиками алгоритма и контекстом применения: задержками, требованиями к памяти, необходимостью параллельной обработки, поддержкой AEAD.

Криптостойкость и модели атак

Криптостойкость не является абсолютной характеристикой. Она всегда оценивается относительно модели атаки — набора предположений о возможностях злоумышленника.

Наиболее сильная модель — атака с полным перебором (brute-force). Здесь предполагается, что атакующий имеет доступ только к шифротексту и пытается подобрать ключ, перебирая все возможные его значения. Время, требуемое для успеха, экспоненциально зависит от длины ключа: 2⁵⁶ попыток для DES, 2¹²⁸ — для AES-128, 2²⁵⁶ — для AES-256. При современных вычислительных мощностях 128-битные ключи считаются безопасными на десятилетия вперёд; 256-битные — практически неуязвимыми в обозримом будущем.

Однако реальные атаки редко ограничиваются полным перебором. Гораздо более опасны:
— атаки по известному открытому тексту, когда злоумышленник владеет парой «открытый текст ↔ шифротекст» (например, стандартные заголовки HTTP);
— атаки по выбранному открытому тексту, где атакующий может заставить систему зашифровать произвольные данные и проанализировать результаты;
— side-channel атаки, эксплуатирующие физические характеристики устройства: время выполнения операций, энергопотребление, электромагнитное излучение. Такие атаки позволяют восстановить ключ без анализа самого алгоритма, лишь наблюдая за его реализацией.

Поэтому при оценке стойкости учитываются не только теоретические свойства алгоритма, но и:
— робастность реализации (постоянное время выполнения, отсутствие утечек памяти);
— корректность использования (неповторяемость инициализирующих векторов, выбор режима);
— отсутствие слабых ключей (значений, при которых алгоритм вырождается).

Стандартизация (например, через NIST — Национальный институт стандартов и технологий США) играет здесь решающую роль. Алгоритмы проходят многолетние публичные криптоаналитические проверки, в ходе которых исследователи по всему миру пытаются найти уязвимости. Только после выдерживания таких «криптографических стресс-тестов» алгоритм может быть рекомендован к массовому применению.

---

Симметричное шифрование

Симметричное шифрование представляет собой класс криптографических схем, в которых один и тот же ключ используется как для преобразования открытого текста в шифротекст, так и для обратного преобразования — восстановления исходных данных. Эта схема является исторически первой и остаётся наиболее широко применяемой в современных системах благодаря своей вычислительной эффективности, простоте реализации и доказанной стойкости.

Принцип симметрии в криптографии означает функциональную идентичность ключа в двух противоположных операциях: шифровании и расшифровании. Формально, если обозначить алгоритм шифрования как функцию E, алгоритм расшифрования — как D, ключ — как K, а открытый текст и шифротекст — как P и C соответственно, то для корректной работы системы выполняется условие:
D(K, E(K, P)) = P.
Это соотношение лежит в основе всех симметричных криптосистем и определяет их фундаментальное ограничение: абсолютная необходимость конфиденциального обмена ключом до начала защищённого взаимодействия.

Архитектурные преимущества и ограничения

Основное преимущество симметричного шифрования — производительность. Алгоритмы, такие как AES или ChaCha20, реализуются с минимальными накладными расходами как в программном, так и в аппаратном исполнении. Современные процессоры включают специальные инструкции (например, AES-NI в архитектуре x86), позволяющие шифровать гигабайты данных в секунду на одном ядре. Это делает симметричные схемы незаменимыми в сценариях, требующих высокой пропускной способности: шифрование дисков, туннелирование сетевого трафика, защита баз данных в реальном времени.

Ограничением, как уже отмечалось, является задача предварительного распределения ключа. Две стороны, желающие обмениваться зашифрованными сообщениями, должны заранее договориться о значении K, сохранив его в тайне от третьих лиц. Если этот обмен производится по тому же каналу, по которому впоследствии будет передаваться защищённая информация, возникает порочный круг: для защиты ключа требуется другой ключ. Эта проблема, известная как проблема начальной синхронизации, не имеет решения в рамках чисто симметричной модели.

Именно поэтому в реальных протоколах симметричное шифрование почти никогда не используется изолированно. Оно комбинируется с асимметричными методами в гибридных схемах. Например, в TLS-соединении ключи для AES генерируются на лету и передаются клиенту, зашифрованные публичным ключом сервера (или согласованы по протоколу Диффи–Хеллмана). Само же шифрование полезной нагрузки — HTTP-запросов, файлов, видеопотока — осуществляется уже симметричным алгоритмом. Таким образом достигается оптимальное сочетание безопасности обмена ключами и скорости обработки данных.

Блочные шифры

Большинство современных симметричных алгоритмов относятся к классу блочных шифров. Их характерная черта — обработка данных фиксированными порциями, называемыми блоками. Размер блока — это внутренний параметр алгоритма, не зависящий от длины передаваемого сообщения. Например:
— AES использует блоки по 128 бит (16 байт);
— его предшественник DES — по 64 бита (8 байт);
— шифр Threefish (используемый в хэш-функции Skein) поддерживает блоки 256, 512 и 1024 бит.

Если входное сообщение короче одного блока, применяется процедура дополнения (padding), чтобы довести его до требуемой длины. Наиболее распространённый стандарт — PKCS#7: если до полного блока не хватает n байт, в конец добавляются n байт, каждый из которых имеет значение n. При расшифровке дополнение однозначно определяется и удаляется. Важно, что некорректная реализация padding может привести к уязвимостям (например, атака Bleichenbacher на RSA PKCS#1 v1.5, или padding oracle в CBC-режиме), поэтому в современных протоколах всё чаще используются режимы без дополнения, такие как CTR или GCM.

Если длина сообщения превышает размер одного блока, алгоритм применяется последовательно к каждому блоку, но с учётом режима работы (mode of operation). Сам по себе блочный шифр определяет, как преобразуется один блок при заданном ключе. Режим же задаёт взаимосвязь между блоками и управляет такими свойствами, как:
— возможность параллельной обработки;
— устойчивость к повторам;
— наличие встроенной аутентификации.

Рассмотрим наиболее значимые режимы:

ECB (Electronic Codebook) — самый простой режим. Каждый блок шифруется независимо с одним и тем же ключом. Его главный недостаток — отсутствие диффузии между блоками: одинаковые фрагменты открытого текста порождают одинаковые фрагменты шифротекста. Это позволяет распознавать структуру данных визуально (знаменитый пример — зашифрованное изображение Ленны в ECB остаётся различимым). Поэтому ECB не рекомендуется для шифрования структурированных данных и почти нигде не используется на практике, кроме как в учебных целях.

CBC (Cipher Block Chaining) — устраняет недостаток ECB за счёт введения цепочки зависимостей. Перед шифрованием каждого блока он комбинируется (с помощью XOR) с шифротекстом предыдущего блока. Для первого блока используется специальное случайное значение — инициализирующий вектор (IV). Благодаря этому одинаковые блоки открытого текста дают разные шифротексты, а изменение одного бита в исходных данных влияет на все последующие блоки. Однако CBC не поддерживает параллельное шифрование (только расшифрование) и уязвим к атакам типа padding oracle, если реализация небезопасна.

CTR (Counter Mode) — превращает блочный шифр в поточный. Вместо шифрования данных напрямую, шифруется последовательность счётчиков (counter), а полученный ключевой поток накладывается на открытый текст с помощью XOR. Это позволяет шифровать и расшифровывать блоки независимо и параллельно, обеспечивает естественную поддержку произвольной длины сообщения без padding и исключает многие уязвимости CBC. Недостаток — критическая зависимость от уникальности счётчика: повторное использование одной пары (ключ, счётчик) приводит к утечке разности открытых текстов.

GCM (Galois/Counter Mode) — является расширением CTR-mode. Помимо шифрования, он вычисляет так называемый аутентификационный тег — краткое значение, подтверждающее целостность и подлинность как зашифрованных, так и незашифрованных, но связанных с сообщением данных (Associated Data). Это реализует шифрование с аутентификацией (AEAD — Authenticated Encryption with Associated Data), что делает GCM предпочтительным выбором для сетевых протоколов (TLS 1.2+, IPsec), где одновременно требуется конфиденциальность и защита от подмены.

Выбор режима определяется требованиями протокола: для дискового шифрования (например, LUKS) часто используется XTS — модификация CBC, устойчивая к атакам по изменению секторов; для передачи в реальном времени — CTR или GCM; для простых случаев, где аутентификация предоставляется отдельно — CBC (с осторожностью).

Основные алгоритмы симметричного шифрования

AES (Advanced Encryption Standard)

AES — текущий мировой стандарт симметричного шифрования, утверждённый NIST в 2001 году по итогам открытого конкурса. Победителем стал алгоритм Rijndael, разработанный бельгийскими криптографами Винсентом Рейменом и Йоаном Даменом. Несмотря на то, что оригинальный Rijndael поддерживал переменный размер блока и ключа, в стандарте AES зафиксирован размер блока 128 бит, а длина ключа может быть 128, 192 или 256 бит, что соответствует уровням безопасности AES-128, AES-192 и AES-256.

Алгоритм построен на раундовой структуре. Количество раундов зависит от длины ключа: 10 для 128-битного, 12 для 192-битного, 14 для 256-битного. Каждый раунд включает четыре операции:
— SubBytes — нелинейная замена байтов по фиксированной таблице (S-блок);
— ShiftRows — циклический сдвиг строк внутреннего состояния;
— MixColumns — линейное перемешивание столбцов (матричное умножение в поле Галуа GF(2⁸));
— AddRoundKey — наложение части ключа (раундового подключа), генерируемого из исходного ключа по алгоритму расширения ключа (Key Schedule).

Эти операции обеспечивают два ключевых свойства, сформулированных Клодом Шенноном: конфузию (сокрытие связи между ключом и шифротекстом) и диффузию (рассеивание влияния одного бита открытого текста по всему шифротексту). После последнего раунда операция MixColumns опускается, что позволяет использовать один и тот же код для шифрования и расшифрования с небольшими модификациями.

AES обладает рядом практических преимуществ:
— отсутствие известных эффективных атак, снижающих его стойкость ниже полного перебора;
— высокая скорость программной реализации;
— эффективность аппаратной реализации (в том числе в микроконтроллерах и FPGA);
— поддержка в криптографических библиотеках всех основных платформ.

ChaCha20-Poly1305

Этот дуэт представляет собой современную альтернативу AES-GCM, особенно актуальную в средах, где отсутствует аппаратная поддержка AES (например, мобильные устройства на ARM без Crypto Extensions или встраиваемые системы).

ChaCha20 — поточный шифр, разработанный Дэниелом Бернштейном как улучшенная версия Salsa20. Он генерирует ключевой поток из 512-битного внутреннего состояния, включающего ключ (256 бит), счётчик (32 бита), nonce (96 бит) и константу. Основная операция — серия из 20 «раундов» (отсюда название), в каждом из которых выполняются простые арифметические действия (сложение по модулю 2³², побитовый сдвиг, XOR). Ключевой поток затем накладывается на открытый текст.

Преимущества ChaCha20:
— высокая скорость на процессорах без специальных инструкций;
— сопротивление side-channel атакам благодаря отсутствию зависимостей от данных в потоке выполнения;
— отсутствие необходимости в padding;
— естественная поддержка произвольной длины сообщения.

Poly1305 — это аутентификационный код, разработанный для пары с ChaCha20. Он вычисляет 128-битный тег, гарантирующий целостность сообщения. Важно, что ключ для Poly1305 должен генерироваться отдельно — обычно первые 256 бит ключевого потока ChaCha20 выделяются именно для этой цели.

Совокупность ChaCha20-Poly1305 включена в стандарт RFC 8439 и широко используется в TLS 1.3, QUIC, Signal Protocol и других современных защищённых протоколах.

Другие алгоритмы

— DES и 3DES — устаревшие алгоритмы. DES (56-битный ключ) считается небезопасным с середины 1990‑х. Triple DES (3DES) — попытка его усилить за счёт троекратного применения с двумя или тремя ключами. Несмотря на теоретическую стойкость ~112 бит, он медленный и подвержен атакам по слабым ключам. NIST официально рекомендовал прекратить его использование после 2023 года.

— Blowfish и Twofish — разработаны Брюсом Шнайером. Blowfish (64-битный блок, ключ до 448 бит) популярен в легаси-системах (например, в утилите bcrypt для хэширования паролей). Twofish был финалистом конкурса AES, но уступил по скорости на 32-битных платформах. Оба алгоритма считаются безопасными, но не стандартизированы так широко, как AES.

— Serpent — ещё один финалист AES, отличающийся повышенным числом раундов (32) и акцентом на максимальную консервативную стойкость. Медленнее AES, но используется в некоторых системах, где безопасность ставится выше производительности (например, в TrueCrypt/VeraCrypt как опция).

— ARIA, Camellia, SM4 — национальные стандарты (Южная Корея, Япония, Китай соответственно). Имеют сходную структуру с AES, но используют другие S-блоки и расписания ключей. Применяются в основном в соответствующих юрисдикциях для соответствия регуляторным требованиям.

Выбор алгоритма в новом проекте почти всегда сводится к AES-GCM или ChaCha20-Poly1305, в зависимости от целевой платформы и требований к аутентификации.

Генерация и хранение ключей

Эффективность симметричного шифрования напрямую зависит от качества ключа. Ключ должен быть:
— достаточной длины (минимум 128 бит для долгосрочной защиты, 256 бит — для максимальной стойкости);
— статистически случайным (все битовые последовательности равновероятны);
— непредсказуемым (невозможно предугадать следующий бит, даже зная все предыдущие);
— уникальным в контексте его использования (например, не должен повторяться в разных сессиях с одним и тем же nonce в CTR/GCM).

Для генерации таких ключей используются криптографически стойкие генераторы псевдослучайных чисел (CSPRNG — Cryptographically Secure Pseudorandom Number Generator). В отличие от стандартных rand() или Math.random(), CSPRNG:
— инициализируются высококачественной энтропией (измерения физических процессов: шум датчиков, временные интервалы между прерываниями и т.п.);
— проходят строгие статистические тесты (NIST SP 800-22);
— устойчивы к предсказанию выхода даже при частичной компрометации внутреннего состояния.

Примеры надёжных CSPRNG:
— /dev/urandom и getrandom() в Linux;
— CryptGenRandom (устар.) и BCryptGenRandom в Windows;
— crypto.getRandomValues() в Web API;
— secrets в Python, crypto.randomBytes в Node.js, SecureRandom в Java.

Хранение ключей — отдельная проблема. В идеале, ключи никогда не должны существовать в открытом виде вне защищённого контекста:
— В оперативной памяти — только на время выполнения операции, с последующим перезаписыванием (wipe);
— На диске — только в зашифрованном виде, с доступом через доверенные компоненты (HSM, TPM, защищённые контейнеры вроде Windows DPAPI или macOS Keychain);
— В конфигурационных файлах — недопустимо в открытом тексте. Допустимо — в виде ссылок на внешние защищённые хранилища (HashiCorp Vault, AWS KMS, Azure Key Vault).

Особое внимание — ключам шифрования ключей (KEK — Key Encryption Key). В иерархических системах мастер-ключ (KEK) используется для шифрования рабочих ключей (DEK — Data Encryption Key). Это позволяет централизованно управлять доступом: при отзыве KEK все защищённые им DEK становятся недоступны, не требуя перешивания самих данных.

Типичные ошибки в реализации симметричного шифрования

Несмотря на зрелость алгоритмов, ошибки возникают на уровне использования. Наиболее распространённые:

1. Повторное использование nonce/IV — фатальная ошибка в режимах CTR, GCM, ChaCha20. При одинаковых паре (ключ, nonce) генерируется идентичный ключевой поток. XOR двух шифротекстов даёт XOR их открытых текстов, что часто позволяет восстановить содержимое (например, если один из текстов известен или имеет предсказуемую структуру — как в HTTP-заголовках). Решение: использовать уникальный, предпочтительно случайный nonce (96 бит для GCM, 96 бит для ChaCha20); при невозможности — счётчик с сохранением состояния.

2. Отсутствие аутентификации — шифрование без проверки целостности. Злоумышленник может изменить шифротекст, и при расшифровании получатель получит искажённые, но синтаксически корректные данные. Например, замена amount=100 на amount=999 в банковском протоколе. Решение: всегда использовать AEAD-режимы (GCM, CCM, ChaCha20-Poly1305) или отдельно применять HMAC с уникальным ключом.

3. Слабая генерация ключей — использование пользовательских паролей напрямую как ключей, без применения функций растяжения ключа (Key Derivation Function, KDF), таких как PBKDF2, scrypt или Argon2. Простые пароли имеют низкую энтропию и поддаются атакам по словарю. KDF добавляют вычислительную сложность и соль (salt), делая перебор экономически невыгодным.

4. Небезопасное управление памятью — хранение ключей в строках (strings), которые могут копироваться в памяти или оставаться после сборки мусора. Лучше использовать специализированные типы, поддерживающие безопасное стирание (например, SecureString в .NET — с оговорками, или ByteArray с ручным fill(0) в Java/C# после использования).

5. Ручная реализация алгоритмов — написание собственного AES «для оптимизации» или «из-за отсутствия библиотек». Это почти гарантированно приводит к side-channel уязвимостям или логическим ошибкам. Рекомендация: использовать только проверенные, прошедшие аудит библиотеки — OpenSSL, BoringSSL, libsodium, .NET System.Security.Cryptography, Java javax.crypto.

---

Асимметричное шифрование

Асимметричное шифрование, также известное как криптография с открытым ключом, представляет собой принципиально иной подход к защите информации, в отличие от симметричных схем. Его основная идея — разделение функций шифрования и расшифрования между двумя математически связанными, но функционально независимыми ключами: открытым (public key) и закрытым (private key).

Открытый ключ может быть свободно распространён без ущерба для безопасности: он предназначен для операций, которые не должны раскрывать содержание данных — в первую очередь, для шифрования и проверки цифровых подписей. Закрытый ключ, напротив, строго сохраняется в секрете его владельцем и используется для обратных операций — расшифрования и создания подписей.

Это разделение решает фундаментальную проблему симметричных систем — необходимость предварительного обмена секретом по защищённому каналу. В асимметричной модели две стороны могут начать защищённое взаимодействие, даже не имея между собой никаких предварительных каналов связи, кроме публичного распространения открытых ключей.

Концептуальные свойства асимметричных схем

Корректная асимметричная криптосистема должна обладать следующими свойствами:

1. Односторонность с лазейкой (trapdoor one-way function) — существует функция, которую легко вычислить в прямом направлении, но практически невозможно обратить без знания дополнительной информации («лазейки»). Например, умножение двух больших простых чисел — тривиальная операция; разложение полученного произведения на множители — вычислительно эквивалентная задача требует ресурсов, недоступных даже для крупнейших суперкомпьютеров при достаточной длине чисел. Закрытый ключ как раз и содержит эту «лазейку» — знание исходных простых чисел.

2. Невозможность вывода закрытого ключа из открытого — даже при полном знании алгоритма и неограниченном доступе к открытому ключу, вычисление соответствующего закрытого ключа должно быть неосуществимо за реальное время. Эта стойкость основана на сложности решения определённых математических задач, считаемых трудными в теории вычислений.

3. Коммутативность операций — в протоколах, таких как Диффи–Хеллман, важна следующая черта: результат совместного применения двух приватных ключей не зависит от порядка. Это позволяет двум сторонам, не обмениваясь секретами напрямую, вычислить общий секрет, известный только им.

Эти свойства обеспечивают три ключевых приложения асимметричной криптографии:
— шифрование с открытым ключом (передача конфиденциальной информации получателю);
— цифровые подписи (подтверждение подлинности и целостности данных);
— безопасное согласование общего секрета (установление сеансового ключа для последующего симметричного шифрования).

Важно понимать, что в чистом виде асимметричное шифрование не используется для передачи больших объёмов данных. Причина — низкая производительность: RSA в тысячи раз медленнее AES, даже на современных процессорах. Поэтому на практике асимметричные методы применяются для подготовительных этапов: обмена ключами, аутентификации, установления доверия. Непосредственное шифрование полезной нагрузки выполняется симметричными алгоритмами.

Алгоритм RSA

RSA — первый практически реализованный и до сих пор наиболее известный алгоритм асимметричной криптографии, названный по первым буквам фамилий его создателей: Рональда Ривеста, Ади Шамира и Леонарда Адлемана (1977).

Безопасность RSA основана на вычислительной сложности задачи разложения большого составного числа на простые множители — так называемой задаче факторизации. Генерация ключевой пары происходит следующим образом:

1. Выбираются два больших простых числа, обычно одинаковой битовой длины (например, по 1024 или 1536 бит для суммарного модуля 2048 или 3072 бит).
2. Вычисляется их произведение — это число становится частью как открытого, так и закрытого ключа и называется модулем.
3. На основе этих простых чисел и их свойств (в частности, функции Эйлера от модуля) вычисляется пара показателей: один — открытая экспонента (обычно фиксированное небольшое число, например, 65537), второй — закрытая экспонента, которая и составляет суть секрета.

Открытый ключ состоит из модуля и открытой экспоненты. Он публикуется и используется для:
— шифрования данных: отправитель возводит сообщение (представленное числом, меньшим модуля) в степень открытой экспоненты по модулю;
— проверки подписи: получатель возводит подпись в степень открытой экспоненты и сравнивает результат с хэшем документа.

Закрытый ключ — это модуль и закрытая экспонента. Он используется для:
— расшифрования: получатель возводит шифротекст в степень закрытой экспоненты по модулю;
— создания подписи: владелец возводит хэш документа в степень закрытой экспоненты.

Ключевое ограничение RSA — длина шифруемого блока. Она строго ограничена размером модуля минус служебные байты дополнения. Для ключа RSA-2048 максимальный размер открытого текста при использовании стандартного дополнения OAEP составляет около 190 байт. Это делает RSA непригодным для шифрования файлов или потоков напрямую.

На практике RSA применяется для:
— шифрования сеансовых ключей (например, в TLS старых версий — клиент генерирует 48-битный pre-master secret, шифрует его открытым ключом сервера и отправляет);
— цифровых подписей (в сочетании с хэш-функцией — например, RSA-PSS с SHA-256);
— сертификатов открытых ключей (X.509), где RSA-ключ подписывается центром сертификации.

Для обеспечения долгосрочной безопасности рекомендуется использовать длину модуля не менее 3072 бит. Ключи длиной 1024 бит считаются уязвимыми к атакам на современном оборудовании и официально не рекомендуются NIST с 2015 года.

Протокол Диффи–Хеллмана

Разработанный в 1976 году Уитфилдом Диффи и Мартином Хеллманом, этот протокол стал первым практическим решением задачи безопасного согласования общего секрета по открытому каналу. Он не является алгоритмом шифрования в узком смысле, но лежит в основе большинства современных криптографических протоколов.

Идея протокола проста: две стороны (традиционно называемые Алисой и Бобом) хотят получить общий секрет S, известный только им, даже если все их сообщения прослушивает Ева. Для этого они используют общие параметры — большое простое число P и базу g (генератор мультипликативной группы по модулю P). Эти параметры могут быть общедоступными или согласованы заранее.

Процесс выглядит так:
— Алиса генерирует случайное число a (её приватный ключ), вычисляет A = gᵃ mod P и отправляет A Бобу.
— Боб генерирует случайное число b, вычисляет B = gᵇ mod P и отправляет B Алисе.
— Алиса вычисляет S = Bᵃ mod P.
— Боб вычисляет S = Aᵇ mod P.

Благодаря свойству коммутативности возведения в степень, оба получают одно и то же значение S = gᵃᵇ mod P. Однако Ева, перехватив A, B, g и P, не может вычислить S, не зная ни a, ни b. Задача вычисления a по A = gᵃ mod P называется задачей дискретного логарифмирования и считается вычислительно трудной при правильном выборе параметров.

Протокол Диффи–Хеллмана не обеспечивает аутентификации участников — он уязвим к атаке «человек посередине» (MITM), когда Ева подменяет A и B своими значениями и устанавливает разные секреты с Алисой и Бобом отдельно. Поэтому в реальных системах он всегда комбинируется с механизмами аутентификации: цифровыми подписями, сертификатами или общим предварительным ключом.

Существует несколько вариантов реализации:
— DH по конечным полям (FFDH) — классическая версия, описанная выше; требует больших модулей (минимум 2048 бит) для стойкости.
— ECDH (Elliptic Curve Diffie–Hellman) — версия на эллиптических кривых, обеспечивающая ту же стойкость при значительно меньших размерах ключей (например, 256-битная кривая даёт уровень безопасности, сопоставимый с RSA-3072). Подробнее — ниже.

Эллиптические кривые

Криптография на эллиптических кривых (ECC — Elliptic Curve Cryptography) — это семейство асимметричных алгоритмов, построенных на алгебраической структуре эллиптических кривых над конечными полями. В отличие от RSA и классического Диффи–Хеллмана, ECC базируется на задаче дискретного логарифмирования в группе точек эллиптической кривой, которая на практике оказывается значительно сложнее для решения при эквивалентной битовой длине.

Преимущества ECC:
— Меньший размер ключей при том же уровне безопасности:
 • 256-битный ключ ECC ≈ 3072-битному ключу RSA;
 • 384-битный ключ ECC ≈ 7680-битному ключу RSA.
— Меньший объём данных в сертификатах и сообщениях — критично для мобильных и IoT-устройств.
— Более высокая производительность на операциях подписи и проверки (особенно на встраиваемых системах).

Наиболее распространённые алгоритмы на основе ECC:

ECDSA (Elliptic Curve Digital Signature Algorithm)

Аналог DSA, перенесённый на эллиптические кривые. Используется для создания и проверки цифровых подписей. Применяется в Bitcoin, Ethereum, сертификатах TLS (например, ECDSA с SHA-256), DNSSEC. Его главный недостаток — необходимость использования криптографически стойкого генератора случайных чисел при каждой подписи: повторное или предсказуемое значение nonce приводит к раскрытию приватного ключа (что неоднократно происходило в практике криптокошельков).

EdDSA (Edwards-curve Digital Signature Algorithm)

Более современная и безопасная альтернатива ECDSA, разработанная на основе кривых Эдвардса (в частности, Curve25519 и Curve448). Отличительная черта — детерминированная генерация nonce: значение вычисляется как хэш от приватного ключа и сообщения, что исключает случайные утечки из-за плохой случайности. Ed25519 (реализация EdDSA на Curve25519) стала де-факто стандартом для новых систем: OpenSSH с версии 6.5, GnuPG 2.1+, Signal Protocol, WireGuard.

ECDH (Elliptic Curve Diffie–Hellman)

Как уже упоминалось, это вариант Диффи–Хеллмана на эллиптических кривых. В TLS 1.3 используется практически исключительно в форме ECDHE (Elliptic Curve Diffie–Hellman Ephemeral) — с временным (эфемерным) ключом для каждой сессии, что обеспечивает Perfect Forward Secrecy.

Выбор конкретной кривой критически важен. Некоторые стандартные кривые (например, NIST P-256) подвергались критике из-за подозрений в заложенных уязвимостях. Поэтому предпочтение отдаётся открытым, прозрачно сгенерированным кривым:
— Curve25519 и Curve448 (RFC 7748) — разработаны Дэниелом Бернштейном, не содержат «магических» констант, оптимизированы для скорости и безопасности;
— secp256k1 — используется в Bitcoin, имеет простую структуру, но менее консервативна в выборе параметров.

Асимметричное шифрование

Несмотря на мощь асимметричных схем, важно чётко понимать их границы:

1. Не обеспечивает конфиденциальность без дополнительных мер. Подпись документа приватным ключом не скрывает его содержание — наоборот, она подтверждает его подлинность, но оставляет текст открытым. Для обеспечения конфиденциальности требуется комбинация: сначала подпись (для аутентичности), затем шифрование (для сокрытия).

2. Уязвимо к атакам подмены ключа. Если злоумышленник может подменить открытый ключ получателя на свой собственный, он сможет расшифровать все сообщения, предназначенные получателю. Отсюда — необходимость инфраструктуры открытых ключей (PKI), где доверие к ключу устанавливается через цепочку сертификатов, подписанных доверенными центрами (CA).

3. Не масштабируется для массовой рассылки. Чтобы отправить одно и то же сообщение N получателям, нужно зашифровать его N раз — по одному для каждого открытого ключа. Для рассылки предпочтительнее гибридные схемы: шифровать симметричный ключ, а его — рассылать каждому получателю асимметрично.

4. Требует строгого управления жизненным циклом ключей. Закрытый ключ — это цифровой аналог печати или подписи. Его компрометация означает полную потерю доверия. Поэтому необходимы процедуры:
    — генерации (на защищённых устройствах, с аудитом);
    — хранения (в HSM или TPM);
    — резервного копирования (с разделением секрета, например, по схеме Шамира);
    — отзыва (через списки отозванных сертификатов — CRL или OCSP);
    — уничтожения (гарантированное стирание, в том числе физическое).

Инфраструктура открытых ключей (PKI)

PKI — это совокупность политик, процедур, программного и аппаратного обеспечения, предназначенных для создания, распределения, управления и отзыва цифровых сертификатов. Сертификат — это структура данных, связывающая открытый ключ с идентификатором владельца (например, доменным именем или ФИО) и заверённая цифровой подписью доверенного центра сертификации (CA — Certificate Authority).

Стандартный формат сертификата — X.509 (ITU-T). Он содержит:
— версию, серийный номер;
— алгоритм подписи;
— имя издателя (CA);
— период действия (not before / not after);
— имя субъекта (владельца ключа);
— открытый ключ субъекта;
— расширения (например, назначение ключа — шифрование, подпись, TLS-сервер);
— цифровую подпись CA.

Процесс получения сертификата:

1. Субъект генерирует ключевую пару локально (закрытый ключ никогда не покидает его устройства).
2. Формирует запрос на сертификат (CSR — Certificate Signing Request), содержащий открытый ключ и идентификационные данные, подписанный своим приватным ключом.
3. Отправляет CSR в CA.
4. CA проверяет право субъекта на владение данными (например, доменом — через DNS-запись или HTTP-файл).
5. При успешной проверке CA подписывает CSR своим приватным ключом и выдаёт сертификат.

Проверка сертификата получателем включает:
— проверку подписи с помощью открытого ключа CA (который должен быть заранее доверенным — встроен в ОС или браузер);
— проверку срока действия;
— проверку отзыва (через CRL или OCSP);
— проверку соответствия имени субъекта ожидаемому (например, example.com в URL и в сертификате).

Доверие в PKI иерархическое: корневые CA (root CA) — самоудостоверяющие сертификаты, распространяемые в составе операционных систем; промежуточные CA (intermediate CA) — подписываются корневыми и выпускают конечные сертификаты. Такая структура позволяет изолировать риски: компрометация промежуточного CA не затрагивает корневой.

Альтернативные модели доверия:
— Web of Trust (сеть доверия) — используется в PGP/GPG. Пользователи самостоятельно подписывают ключи друг друга, и доверие распространяется по цепочке подписей. Гибко, но плохо масштабируется.
— TOFU (Trust-On-First-Use) — применяется в SSH и Signal. Ключ принимается как доверенный при первом использовании и запоминается; при изменении — выдаётся предупреждение. Подходит для peer-to-peer сценариев.

Современные тенденции

1. Переход на эллиптические кривые. В TLS 1.3 поддержка RSA для согласования ключей удалена — оставлены только (EC)DHE. Это ускоряет установку соединения и обеспечивает PFS по умолчанию.

2. Постквантовая криптография (PQC). С развитием квантовых компьютеров алгоритмы RSA и ECC становятся уязвимыми к атаке Шора, которая эффективно решает задачи факторизации и дискретного логарифмирования. NIST ведёт процесс стандартизации постквантовых алгоритмов, основанных на других математических задачах:
    — решётках (Lattice-based, например, CRYSTALS-Kyber для обмена ключами, CRYSTALS-Dilithium для подписей);
    — хэш-функциях (например, SPHINCS+);
    — кодах исправления ошибок (Classic McEliece).
   Первые стандарты ожидаются в 2024–2025 годах; гибридные схемы (классический + постквантовый) уже тестируются в экспериментальных версиях TLS.

3. Минимизация поверхности атаки. Современные протоколы стремятся к «криптографическому минимализму»: меньше выбора алгоритмов, меньше параметров, меньше возможностей для неправильной конфигурации. Пример — TLS 1.3: удалены небезопасные шифры (RC4, DES, CBC без AEAD), отключены статические RSA-ключи, упрощён handshake.

---

Хэширование

Хэширование — это процесс преобразования последовательности данных произвольной длины в значение фиксированной длины, называемое хэшем, хэш-суммой или дайджестом. В отличие от шифрования, хэширование является необратимым (односторонним) преобразованием: по полученному хэшу невозможно восстановить исходные данные, даже при знании алгоритма. Эта особенность определяет его основное назначение — проверка целостности и подлинности, а не сокрытие информации.

Криптографическое хэширование — это не просто сжатие данных. Оно реализует строгий набор математических свойств, обеспечивающих гарантии, необходимые для безопасности. Если алгоритм не обладает этими свойствами, его использование в защитных механизмах становится опасным.

Свойства криптографических хэш-функций

Для того чтобы хэш-функция считалась криптографически стойкой, она должна удовлетворять трём ключевым требованиям:

1. Устойчивость к поиску прообраза (preimage resistance)
   По заданному хэш-значению h должно быть вычислительно невозможно найти любое сообщение m, такое что hash(m) = h. Это свойство гарантирует, что хэш нельзя «расшифровать» — даже если злоумышленник знает дайджест, он не сможет подобрать исходные данные. Например, при хранении хэшей паролей в базе данных атакующий не может восстановить пароль по его хэшу.

2. Устойчивость к поиску второго прообраза (second preimage resistance)
   По заданному сообщению m₁ должно быть вычислительно невозможно найти другое сообщение m₂ ≠ m₁, такое что hash(m₁) = hash(m₂). Эта гарантия важна для систем, где требуется подтверждение неизменности конкретного документа: если отправитель передал хэш от контракта, получатель может убедиться, что полученный файл действительно соответствует тому, что имел в виду отправитель.

3. Устойчивость к коллизиям (collision resistance)
   Должно быть вычислительно невозможно найти любую пару различных сообщений m₁ ≠ m₂, для которых hash(m₁) = hash(m₂). Это самое сильное требование. Его нарушение позволяет подменить одно сообщение другим, имеющим тот же хэш, не нарушая проверок целостности. Исторически слабость этого свойства привела к отказу от MD5 и SHA-1: для MD5 были построены коллизии менее чем за секунду на обычном ПК; для SHA-1 — в 2017 году в рамках проекта SHAttered.

Важно понимать иерархию этих свойств: если функция не устойчива к коллизиям, она автоматически не устойчива к поиску второго прообраза и, возможно, к поиску прообраза (хотя теоретически возможны функции, устойчивые к коллизиям, но не к прообразу — на практике такие не используются).

Дополнительные, но важные характеристики: — Лавинный эффект — изменение даже одного бита входных данных должно вызывать радикальное изменение хэша (в среднем, ~50 % битов дайджеста меняются). Это свойство предотвращает анализ зависимости между данными и их хэшем. — Детерминированность — одинаковые входные данные всегда порождают один и тот же хэш. Без этого невозможно проверять целостность. — Фиксированная длина выхода — независимо от размера входа (1 байт или 1 ТБ), дайджест имеет строго определённую длину (например, 256 бит для SHA-256). Это позволяет эффективно сравнивать и хранить контрольные суммы.

Эволюция алгоритмов хэширования

MD5 и SHA-1

MD5 (Message Digest 5), разработанный Роном Ривестом в 1992 году, выдаёт 128-битный дайджест. Несмотря на изначальную популярность (использовался в протоколах, дистрибутивах, контрольных суммах), к середине 2000-х были обнаружены эффективные методы построения коллизий. Уже в 2004 году Ван Сюэцзя построила первую практическую коллизию MD5; в 2008 году продемонстрирована подделка SSL-сертификата с использованием MD5-коллизий. Сегодня MD5 считается полностью небезопасным для любых криптографических целей и рекомендуется только для несекьюрных задач — например, как быстрый идентификатор дубликатов файлов в локальной системе.

SHA-1 (Secure Hash Algorithm 1), разработанный NSA и принятый NIST в 1995 году, выдаёт 160-битный дайджест. Более стойкий, чем MD5, но также подвергся постепенному ослаблению. Теоретические атаки появились ещё в 2005 году; в 2017 году Google и CWI реализовали полную коллизию (SHAttered) за ~110 тыс. GPU-часов — достижимо для хорошо финансируемой группы. В результате NIST рекомендовал прекратить использование SHA-1 после 2010 года для цифровых подписей и сертификатов; все основные браузеры прекратили его поддержку в TLS к 2017 году.

SHA-2: текущий стандарт

SHA-2 — семейство хэш-функций, разработанное NSA и стандартизированное NIST в 2001 году как замена SHA-1. В его состав входят: — SHA-224 и SHA-256 — с 32-битными словами, дайджесты 224 и 256 бит; — SHA-384 и SHA-512 — с 64-битными словами, дайджесты 384 и 512 бит; — SHA-512/224 и SHA-512/256 — усечённые версии SHA-512 для совместимости.

Строение SHA-2 основано на схеме Меркля–Дамгора: входное сообщение дополняется (padding), разбивается на блоки, каждый блок последовательно обрабатывается с использованием сжимающей функции и текущего состояния. Особое внимание уделено нелинейным операциям и константам, сгенерированным на основе дробных частей квадратных корней простых чисел — это снижает риск скрытых уязвимостей.

SHA-256 стал де-факто стандартом: используется в TLS, PGP, SSH, Git (хэши коммитов и объектов), Bitcoin (двойной SHA-256 для адресов и блоков), цифровых подписях, контрольных суммах дистрибутивов. На 2025 год неизвестно ни одной практической атаки, снижающей его стойкость ниже уровня полного перебора (2¹²⁸ для SHA-256, что вычислительно недостижимо).

SHA-3 и BLAKE: новые поколения

SHA-3 — результат открытого конкурса NIST, завершённого в 2015 году. Победителем стал алгоритм Keccak, предложенный бельгийскими криптографами. Несмотря на название, SHA-3 не является заменой SHA-2, а представляет собой альтернативную конструкцию с иной внутренней структурой — sponge construction («губка»). Входные данные «впитываются» в внутреннее состояние, затем из него «выжимается» дайджест нужной длины.

Преимущества SHA-3: — теоретическая устойчивость даже к гипотетическим атакам, успешным против SHA-2 (например, некоторые виды дифференциального криптоанализа); — гибкость: одна и та же функция может использоваться как хэш, MAC, генератор случайных чисел, поточный шифр; — устойчивость к length-extension атакам (характерным для SHA-2 и MD5), где злоумышленник, зная hash(m), может вычислить hash(m || padding || x) без знания m.

Однако внедрение SHA-3 идёт медленно из-за отсутствия острой необходимости и высокой эффективности SHA-2 на существующем оборудовании.

BLAKE и BLAKE2 — альтернативное семейство, разработанное как финалист того же конкурса SHA-3. BLAKE2, в частности, превосходит SHA-2 и SHA-3 по скорости на большинстве платформ, обладает встроенной поддержкой ключей (для HMAC-подобных сценариев), параллелизации и деревьев хэширования (актуально для больших файлов). Используется в системах хранения (ZFS, IPFS), криптовалютах (Zcash), протоколах (Noise Protocol Framework). BLAKE3 — упрощённая и ускоренная версия, оптимизированная для современных CPU.

Выбор алгоритма на практике: — SHA-256 — универсальный выбор для новых систем (TLS, API, контрольные суммы);
— SHA-512 — при необходимости более высокой стойкости или на 64-битных системах (часто быстрее SHA-256);
— BLAKE2b/BLAKE3 — когда критична производительность и требуется модернизация;
— SHA-3 — в регуляторных сценариях, требующих разнообразия алгоритмов (например, для защиты от общих уязвимостей).

Применение хэширования в информационных системах

Контроль целостности данных

Простейшее применение — проверка неизменности при передаче или хранении. Отправитель вычисляет хэш от файла и публикует его отдельно (например, на официальном сайте). Получатель скачивает файл, самостоятельно вычисляет хэш и сравнивает со справочным значением. Если значения совпадают, с высокой степенью уверенности можно утверждать, что данные не были повреждены и не были подменены.

Примеры: дайджесты дистрибутивов Linux (.sha256sum), контрольные суммы в протоколах HTTP (ETag), системы контроля версий (Git — каждый объект идентифицируется своим SHA-1/SHA-256 хэшем, что гарантирует неизменность истории).

Хранение паролей

Здесь хэширование применяется с дополнительными мерами, так как простой хэш от пароля уязвим к атакам по словарю и радужным таблицам. Используется трёхуровневая защита:

1. Соль (salt) — случайное уникальное значение, добавляемое к паролю перед хэшированием. Соль хранится в открытом виде рядом с хэшем. Её задача — сделать невозможным использование предвычисленных таблиц: даже для одинаковых паролей хэши будут различаться.

2. Функция растяжения ключа (KDF — Key Derivation Function) — специально замедленный итерационный процесс, многократно применяющий хэш-функцию (или шифр). Это повышает стоимость перебора: если один хэш вычисляется за 100 мс, то проверка 1 млн паролей займёт ~28 часов вместо нескольких секунд.

3. Адаптивность — параметры KDF (число итераций, объём памяти, степень параллелизма) должны регулярно увеличиваться с ростом вычислительных мощностей.

Рекомендуемые KDF:
— PBKDF2 (Password-Based Key Derivation Function 2) — основан на HMAC, стандартизирован в RFC 2898. Прост в реализации, но уязвим к ускорению на GPU/ASIC.
— scrypt — добавляет требование к объёму памяти, что затрудняет параллельные атаки. Используется в Litecoin.
— Argon2 — победитель конкурса Password Hashing Competition (2015). Имеет две модификации: Argon2i (устойчив к side-channel), Argon2d (устойчив к атакам по времени), Argon2id (гибрид). Рекомендован IETF как текущий стандарт (RFC 9106).

Цифровые подписи и цепочки доверия

Хэширование неотделимо от асимметричной криптографии. При создании цифровой подписи подписывается не само сообщение, а его хэш. Это решает две проблемы:
— ограничение длины: RSA не может подписать сообщение длиннее модуля; хэш имеет фиксированную длину;
— эффективность: хэширование быстрее, чем асимметричная операция над многомегабайтным файлом.

Стандарты подписей (например, RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA, EdDSA) строго определяют алгоритм хэширования (обычно SHA-256 или SHA-512) и формат объединения хэша с дополнением. Подмена алгоритма хэширования на более слабый (например, SHA-1 вместо SHA-256) может разрушить безопасность всей схемы.

Структуры данных и протоколы

— Merkle tree (дерево Меркля) — иерархическая структура, где листья — хэши блоков данных, а каждый родительский узел — хэш от конкатенации дочерних. Корневой хэш представляет собой компактный «отпечаток» всего набора данных. Используется в блокчейнах (Bitcoin, Ethereum), системах синхронизации (rsync, Git), распределённых базах данных.

— Хэш-таблицы — структуры данных, использующие хэш для быстрого поиска. Здесь важна равномерность распределения и минимизация коллизий, но криптостойкость не требуется — используются быстрые не криптографические функции (например, MurmurHash, xxHash).

HMAC

HMAC (Hash-based Message Authentication Code) — это механизм построения кода аутентификации сообщения на основе криптографической хэш-функции и общего секретного ключа. Его цель — обеспечить как целостность, так и аутентичность: получатель может убедиться, что сообщение не было изменено и что оно действительно отправлено тем, кто обладает общим ключом.

HMAC не является отдельной хэш-функцией. Это конструктор, который может быть применён к любой итерационной хэш-функции (MD5, SHA-1, SHA-256 и т.д.), хотя для безопасности следует использовать только стойкие основы — например, HMAC-SHA256.

Механизм HMAC использует два прохода хэширования с двумя производными от ключа значениями (внутренний и внешний паддинги — ipad и opad). Формально:
HMAC(K, m) = H((K ⊕ opad) || H((K ⊕ ipad) || m)),
где H — хэш-функция, K — ключ, m — сообщение, || — конкатенация, ⊕ — XOR.

Важные свойства HMAC: — Безопасность доказана в предположении, что основная хэш-функция является «сжимающей» и устойчивой к коллизиям. — Устойчив к length-extension атакам даже при использовании уязвимых хэшей (например, SHA-1). — Ключ может быть любой длины (но рекомендуется равной размеру блока хэша: 64 байта для SHA-256).

Применения HMAC: — API-аутентификация — клиент подписывает запрос (путь, параметры, timestamp) секретным ключом; сервер проверяет подпись. Гарантирует, что запрос не подделан и не повторно использован (при наличии timestamp/nonce). — JWT (JSON Web Tokens) — в режиме HS256/HS512 токен подписывается HMAC с общим секретом (в отличие от RS256/ES256, где используется асимметричная подпись). — TLS — в устаревших версиях (до 1.2) HMAC использовался для аутентификации записей в CBC-режиме (после шифрования). В TLS 1.3 заменён на AEAD-режимы. — Целостность cookies, сессий, конфигураций — добавление HMAC-метки к данным позволяет обнаружить любую подмену.

Ключевые различия: шифрование, хэширование, кодирование, подпись

Для избежания путаницы полезно сопоставить четыре часто смешиваемых понятия:

Механизм	Обратимость	Ключ	Основная цель	Примеры
Шифрование	Обратимо	Да (симметричный или асимметричный)	Конфиденциальность	AES-GCM, RSA-OAEP, ChaCha20-Poly1305
Хэширование	Необратимо	Нет	Целостность, идентификация	SHA-256, BLAKE3, Argon2
Кодирование	Обратимо	Нет	Представление данных в другом формате	Base64, Hex, URL-encoding
Цифровая подпись	Частично обратимо¹	Да (асимметричный)	Аутентичность, неотказуемость	RSA-PSS, ECDSA, Ed25519

¹ Подпись сама по себе необратима, но её можно проверить с помощью публичного ключа.

Base64, например, часто ошибочно принимают за шифрование. На самом деле это просто способ представить бинарные данные в виде ASCII-строки: каждый блок из 3 байт преобразуется в 4 символа из алфавита A–Z, a–z, 0–9, +, /. Декодирование тривиально и не требует ключа. Base64 применяется для передачи бинарных данных в текстовых протоколах (например, вложения в email, токены в HTTP-заголовках), но не обеспечивает никакой защиты.

---

Цифровая подпись и электронная цифровая подпись

Цифровая подпись — это криптографический механизм, обеспечивающий три ключевых свойства информационного объекта:
— аутентичность — подтверждение личности или идентификатора отправителя;
— целостность — гарантия того, что данные не были изменены после подписания;
— неотказуемость (non-repudiation) — техническая невозможность для отправителя отрицать факт подписания.

Электронная цифровая подпись (ЭЦП) — это правовой и технический термин, закреплённый в законодательстве ряда стран (включая Россию), обозначающий цифровую подпись, удовлетворяющую установленным нормативным требованиям и обладающую юридической силой, сопоставимой с собственноручной подписью.

Следует различать «цифровую подпись» как криптографический примитив и «ЭЦП» как институт цифрового документооборота. Первое — технологическая основа; второе — её правовое и процедурное оформление.

Принцип работы

Процесс формирования цифровой подписи состоит из двух логических этапов, хотя на практике они выполняются единым алгоритмом:

1. Хэширование документа. Исходные данные (текст, файл, JSON-объект) подвергаются криптографическому хэшированию с использованием стойкой функции — например, SHA-256, SHA-512 или ГОСТ Р 34.11-2012 (Стрибог). Результат — дайджест фиксированной длины, однозначно характеризующий содержание документа. Любое изменение хотя бы одного бита входных данных приведёт к совершенно иному хэшу.

2. Шифрование хэша закрытым ключом. Полученный дайджест подвергается асимметричному преобразованию с использованием приватного ключа владельца. Технически это применение обратимой функции, доступной только владельцу ключа. Результат — собственно подпись: последовательность байтов, привязанная к документу и к идентификатору ключа.

Важно: подпись не содержит исходного документа. Она сопровождает его как отдельное поле (в файле, метаданных, HTTP-заголовке). Размер подписи определяется параметрами алгоритма:
— RSA-PSS с SHA-256 — 256 байт при 2048-битном ключе;
— ECDSA на кривой P-256 — 64 байта;
— Ed25519 — 64 байта;
— ГОСТ Р 34.10-2012 — 64 байта.

Процесс проверки выполняется получателем следующим образом:

1. Получатель вычисляет хэш от полученного документа с использованием того же алгоритма, что и отправитель.
2. Применяет к подписи операцию расшифрования (точнее — верификации) с помощью открытого ключа отправителя. Результат — дайджест, вычисленный отправителем.
3. Сравнивает полученные два хэша.
4. Если значения совпадают — подпись корректна: документ подлинный, неизменённый, и его подписал владелец приватного ключа.

Если хотя бы один бит документа или подписи нарушен, проверка завершится неудачей. Это обеспечивает детектирование как случайных повреждений (битые сектора, сетевые ошибки), так и злонамеренных подмен.

Алгоритмы цифровых подписей

RSA-PSS и RSASSA-PKCS1-v1_5

RSA может использоваться для шифрования и для подписи. Существует два стандарта форматирования:
— RSASSA-PKCS1-v1_5 — устаревший, но широко используемый (в X.509-сертификатах, S/MIME). Уязвим к некоторым атакам при некорректной реализации (например, атаки на подпись с известным префиксом).
— RSA-PSS (Probabilistic Signature Scheme) — современный стандарт (RFC 8017), использующий случайную соль, что повышает стойкость и формально доказуемо безопасен в модели случайного оракула.

Оба требуют использования стойкого хэша (SHA-256 и выше) и ключей длиной не менее 3072 бит для долгосрочной защиты.

ECDSA (Elliptic Curve Digital Signature Algorithm)

Стандарт NIST, основанный на эллиптических кривых (P-256, P-384, P-521). Обеспечивает высокую стойкость при компактных подписях. Широко применяется в TLS (сертификаты серверов), DNSSEC, криптовалютах (Bitcoin использует модификацию secp256k1).

Уязвимость ECDSA — зависимость от качества случайности при генерации временного параметра k. Если k повторяется или предсказуем (как в случае с уязвимым ГПСЧ в Android Bitcoin-кошельке 2013 года), приватный ключ восстанавливается аналитически из двух подписей. Этого недостатка лишён EdDSA.

EdDSA и Ed25519

EdDSA — современный стандарт, использующий кривые Эдвардса (в первую очередь Curve25519). Подпись детерминирована: параметр k вычисляется как хэш от приватного ключа и сообщения, что исключает случайные утечки. Ed25519 — конкретная реализация с 256-битной стойкостью, высокой скоростью и простотой реализации без side-channel уязвимостей.

Применяется в OpenSSH (с 6.5), GnuPG 2.1+, Signal Protocol, WireGuard, TLS 1.3. Де-факто стандарт для новых систем.

ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012 (Стрибог)

Российские стандарты, входящие в набор «криптография на эллиптических кривых».
— ГОСТ Р 34.10-2012 определяет алгоритм цифровой подписи на эллиптических кривых над простым полем. Поддерживает три набора параметров:
 • id-GostR3410-2001-CryptoPro-A (устаревший, 256-битный);
 • id-tc26-gost-3410-2012-256-paramSetA (текущий, 256-битный);
 • id-tc26-gost-3410-2012-512-paramSetA (512-битный).
— ГОСТ Р 34.11-2012 («Стрибог») — хэш-функция, заменившая устаревший ГОСТ 34.11-94. Выдаёт дайджесты 256 или 512 бит.

Особенности ГОСТ-подписи:
— Длина подписи — 64 байта (256-битная версия), как у ECDSA;
— Алгоритм не использует случайные параметры — подпись детерминирована, как в EdDSA;
— Требует обязательного сертифицирования средств криптографической защиты информации (СКЗИ) ФСБ России для применения в государственных системах.

ГОСТ-подпись применяется в СМЭВ, ЕПГУ, ГИС ЖКХ, ЕГАИС, системах электронного документооборота (СЭД) государственных органов, а также в корпоративных системах, где требуется соответствие 152-ФЗ и 187-ФЗ.

Форматы и стандарты электронных подписей

Подпись редко существует изолированно. Она встраивается в документы и протоколы с соблюдением строгих форматов:

X.509 и PKCS#7 / CMS

X.509 — стандарт сертификатов открытых ключей (ITU-T). PKCS#7 (Public-Key Cryptography Standards #7), переработанный как CMS (Cryptographic Message Syntax, RFC 5652) — формат для подписанных и зашифрованных сообщений.

CMS поддерживает:
— присоединённую подпись (attached) — документ и подпись хранятся вместе (например, .p7s файл, подписанный PDF в Adobe);
— отсоединённую подпись (detached) — подпись хранится отдельно, документ остаётся в исходном виде (например, .sig файл для образа диска).

CMS включает сертификат отправителя, цепочку доверия, атрибуты (временная метка, политика подписи), что позволяет верифицировать подпись даже при отсутствии предварительного обмена ключами.

CAdES (CMS Advanced Electronic Signatures)

Расширение CMS, стандартизированное ETSI (EN 319 122), добавляющее атрибуты для длительного хранения:
— временная метка (включая доверенную от TSP — Time-Stamping Authority), фиксирующая момент подписания;
— архивная метка (для доказательства стойкости через десятилетия);
— политика подписи (ссылка на юридические и технические требования).
Используется в ЕС для квалифицированной ЭЦП (QES — Qualified Electronic Signature), имеющей максимальную юридическую силу.

XAdES (XML Advanced Electronic Signatures)

Аналог CAdES для XML-документов (EN 319 132). Позволяет подписывать отдельные элементы XML, вкладывать сертификаты, временные метки, политики внутрь XML-структуры. Применяется в системах электронного обмена документами (EDI), УПД, СФ в формате XML по приказу ФНС.

PAdES (PDF Advanced Electronic Signatures)

Стандарт (EN 319 142) для встраивания ЭЦП в PDF-файлы с сохранением визуального отображения (штамп, подпись, ФИО). Поддерживается Adobe Acrobat, LibreOffice, Контур.Диадок и другими СЭД.

Открытые форматы: detached JWS, minisign, signify

— JWS (JSON Web Signature, RFC 7515) — компактный формат для подписи JSON-объектов (часто используется в JWT, API, микросервисах). Поддерживает как HMAC (общий ключ), так и асимметричные алгоритмы (RS256, ES256, EdDSA).
— minisign / signify — упрощённые инструменты для подписи файлов, созданные для OpenBSD и портированные в другие ОС. Фокус на простоту, безопасность (только Ed25519), отсутствие зависимостей.

Практические сценарии применения

Электронный документооборот (ЭДО)

В России ЭЦП является основой для юридически значимого обмена документами между юрлицами и ФНС. Подписываются:
— счета-фактуры (в формате XML или PDF/A-3 с вложением XML);
— акты, накладные, договоры (в формате PDF с PAdES или XML с XAdES);
— отчётность (СЗВ-ТД, 6-НДФЛ, РСВ) — через операторов ЭДО (СБИС, Диадок, Тензор).

Ключевые требования:
— сертификат должен быть выдан аккредитованным УЦ (например, КриптоПро, УЦ ФНС, СКБ Контур);
— приложение должно поддерживать ГОСТ-алгоритмы и работать с СКЗИ (например, КриптоПро CSP);
— для некоторых документов требуется квалифицированная ЭЦП (КЭП), где приватный ключ генерируется и хранится на сертифицированном носителе (Рутокен, eToken).

Подпись программного обеспечения

Цель — подтвердить подлинность издателя и отсутствие модификаций после сборки.

— Authenticode (Microsoft) — подписывает исполняемые файлы (.exe, .dll), драйверы, MSI. Использует X.509-сертификаты, обычно RSA или ECDSA. Подпись встраивается в PE-заголовок. Проверяется при запуске (SmartScreen) и установке драйверов.
— Apple Code Signing — подписывает приложения для macOS/iOS. Требует сертификата от Apple Developer. Включает «время подписания» — даже после истечения срока действия сертификата приложение остаётся запускаемым, если было подписано до отзыва.
— GPG/PGP — открытая модель: разработчик публикует отпечаток своего ключа, пользователи проверяют подпись дистрибутива (.asc файл). Используется в Linux (подписи репозиториев, образов ISO).

TLS/SSL и веб-безопасность

Сертификат сервера в TLS содержит открытый ключ и подписан приватным ключом центра сертификации (CA). При установке соединения клиент:

1. Получает сертификат сервера;
2. Проверяет цепочку доверия до корневого CA;
3. Извлекает открытый ключ сервера;
4. Использует его для проверки подписи в ServerKeyExchange (в (EC)DHE) или для шифрования pre-master secret (в устаревшем RSA key transport).

Таким образом, цифровая подпись обеспечивает аутентификацию сервера и предотвращает MITM-атаки.

Блокчейн и распределённые реестры

В системах типа Bitcoin, Ethereum, Polkadot каждая транзакция подписывается приватным ключом владельца адреса. Узлы сети проверяют подпись перед включением транзакции в блок.
— Bitcoin — ECDSA на кривой secp256k1;
— Ethereum — аналогично;
— Cardano, Polkadot, Solana — Ed25519 или его модификации.

Подпись здесь заменяет логин/пароль: владение приватным ключом = право распоряжаться средствами. Ошибка в реализации (например, повторное k в ECDSA) ведёт к прямой краже активов.

Юридическая значимость и инфраструктурная поддержка

В России правовой основой ЭЦП являются:
— Федеральный закон № 63-ФЗ «Об электронной подписи» (в ред. 2021 г.);
— Приказ Минцифры № 474 от 2022 г. — перечень требований к СКЗИ и УЦ;
— ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012 — обязательные алгоритмы для усиленной КЭП.

Виды ЭЦП по 63-ФЗ:

1. Простая — например, SMS-код или логин/пароль. Подтверждает факт действия, но не тождественна собственноручной подписи.
2. Усиленная неквалифицированная — криптографическая подпись, не требующая аккредитованного УЦ. Используется внутри организаций. Юридическая сила определяется соглашением сторон.
3. Усиленная квалифицированная (КЭП) — создаётся с использованием СКЗИ, сертифицированного ФСБ, ключ выдаётся аккредитованным УЦ, включает доверенную временную метку. Имеет полную юридическую силу по умолчанию (ст. 4 63-ФЗ).

Ключевые элементы инфраструктуры:
— Удостоверяющий центр (УЦ) — организация, выпускающая и отзывающая сертификаты. Должен быть аккредитован Минцифры.
— Средство криптографической защиты информации (СКЗИ) — программно-аппаратный комплекс, реализующий ГОСТ-алгоритмы, прошедший сертификацию ФСБ (например, КриптоПро CSP, ВипNet CSP, Signal-COM).
— Носитель ключа — защищённое устройство (Рутокен, JaCarta, eToken), где приватный ключ генерируется и никогда не покидает чипа. Обязателен для КЭП.
— Служба временных меток (TSP) — предоставляет доверенное время, критически важное для доказательства момента подписания.

Особое внимание — доверенной временной метке (RFC 3161). Без неё подпись может быть признана недействительной, если сертификат истёк или был отозван после подписания. Временная метка, выданная TSP с собственной КЭП, «замораживает» статус сертификата на момент подписи.

Типичные ошибки и угрозы

1. Использование устаревших алгоритмов — подпись RSA с SHA-1 или ГОСТ 34.10-2001 в 2025 году не соответствует требованиям 152-ФЗ и уязвима к коллизиям.

2. Отсутствие привязки к времени — подпись без временной метки теряет доказательную силу при смене сертификата.

3. Хранение приватного ключа в открытом виде — например, в файле key.pem на сервере. Даже при сильном пароле это нарушает требования к КЭП.

4. Подпись без проверки отозванности — валидация сертификата без запроса к OCSP или загрузки CRL позволяет использовать скомпрометированные ключи.

5. Некорректная реализация привязки подписи к документу — например, подпись только части XML (без нормализации), что позволяет вставить вредоносный элемент в неподписанный фрагмент (атака «XML Signature Wrapping»).

---

Кодирование данных

Кодирование — это процесс преобразования последовательности байтов из одной формы представления в другую без изменения содержания и без использования секретного ключа. В отличие от шифрования и хэширования, кодирование является полностью обратимым и детерминированным: по закодированной строке всегда можно однозначно восстановить исходные данные. Его цель — обеспечение корректной передачи, хранения или интерпретации данных в средах с ограничениями на допустимые символы.

Несмотря на простоту, кодирование играет критическую роль в работе современных информационных систем: без него невозможны вложения в электронную почту, передача бинарных токенов в HTTP-заголовках, хранение произвольных данных в JSON или XML, совместимость между различными кодовыми страницами и протоколами.

Основные принципы и отличия от криптографических примитивов

Ключевые отличия кодирования от шифрования и хэширования:

Признак	Кодирование	Шифрование	Хэширование
Обратимость	Полная и тривиальная	Полная, но требует ключа	Необратимо
Ключ	Отсутствует	Обязателен	Отсутствует
Цель	Представление данных	Конфиденциальность	Целостность, идентификация
Безопасность	Не обеспечивается	Обеспечивается при корректном использовании	Обеспечивается при стойком алгоритме
Пример	Base64, Hex	AES-GCM, ChaCha20	SHA-256, BLAKE3

Непонимание этих различий приводит к грубым архитектурным ошибкам: например, использование Base64 «для защиты паролей» или интерпретация хэша как зашифрованного значения. Base64 не скрывает данные — он лишь делает их «читаемыми» для текстовых систем. Любой, кто получит строку cGFzc3dvcmQ=, без труда декодирует её в password. Это эквивалентно написанию секрета маркером на стекле: информация видна, просто в другом формате.

Кодирование всегда применяется в сочетании с криптографическими методами: например, сначала данные шифруются (AES), затем шифротекст кодируется в Base64 для передачи в JSON; или пароль хэшируется (Argon2), затем дайджест представляется в Hex для хранения в базе.

Base64

Base64 — наиболее распространённая схема кодирования, стандартизированная в RFC 4648. Её суть — представление каждых трёх байтов (24 бита) исходных данных в виде четырёх символов из 64-символьного алфавита:
A–Z, a–z, 0–9, +, /
(в URL-safe варианте + и / заменяются на - и _).

Процесс:

1. Входной поток байтов разбивается на группы по 3 байта (24 бита).
2. Каждая группа интерпретируется как четыре 6-битных значения (0–63).
3. Каждое значение заменяется соответствующим символом алфавита.
4. Если длина входа не кратна 3, добавляются символы = (padding) до кратности 4 в выходе.

Пример:
Hello → байты [72, 101, 108, 108, 111]
→ группы: [72,101,108], [108,111] (неполная)
→ 6-битные индексы: 19, 22, 5, 0, 27, 47, 15
→ символы: S, G, V, s, b, v, P
→ с padding: SGVsbG8= (6 байт → 8 символов).

Особенности Base64:
— Увеличение объёма на ~33 % (3 байта → 4 символа);
— Отсутствие потерь: декодирование восстанавливает исходные байты бит в бит;
— Не зависит от кодировки текста: кодирует байты, а не символы;
— Поддерживается во всех языках и протоколах.

Сценарии применения:
— Вложения в email (MIME, RFC 2045) — изображения, PDF в теле письма;
— Передача бинарных токенов в HTTP-заголовках (например, Authorization: Basic base64(login:pass));
— Хранение шифротекста или подписи в текстовых форматах (JSON, XML, YAML);
— Data URI в HTML/CSS (<img src="data:image/png;base64,...">);
— Экспорт/импорт ключей в PEM-формате (-----BEGIN PRIVATE KEY----- и т.д.).

Варианты Base64:
— Стандартный (+, /, =) — для общего использования;
— URL- и filename-safe (RFC 4648, §5) — замена + → -, / → _, padding часто опускается (например, в JWT);
— Base64 без padding — используется в протоколах, где длина известна из контекста (например, в некоторых реализациях OAuth2).

Типичные ошибки:
— Попытка использовать Base64 как «лёгкое шифрование» — полная иллюзия безопасности;
— Некорректная обрезка padding при копировании — приводит к ошибкам декодирования;
— Перекодирование уже закодированной строки — экспоненциальный рост размера (Base64(Base64(...)));
— Смешение кодировок: Base64 от UTF-8 строки ≠ Base64 от той же строки в Windows-1251.

Hex (шестнадцатеричное представление)

Hex — кодирование, при котором каждый байт (8 бит) представляется двумя шестнадцатеричными цифрами: 0–9, a–f (иногда A–F). Диапазон одного байта 0–255 соответствует 00–ff.

Пример:
Hi → байты [72, 105] → 48 69 → строка "4869".

Преимущества Hex:
— Простота интерпретации: каждый символ напрямую соответствует 4 битам (полубайту);
— Читаемость для разработчиков (отладка, логи, дампы памяти);
— Отсутствие проблем с экранированием в большинстве языков.

Недостатки:
— Увеличение объёма на 100 % (1 байт → 2 символа);
— Меньше символов алфавита — ниже плотность информации по сравнению с Base64.

Применение:
— Логи и дампы (MAC-адреса 01:23:45:67:89:ab, хэши в Git a1b2c3...);
— Хранение хэшей и UUID в базах данных (столбцы типа CHAR(64) для SHA-256);
— Конфигурационные файлы, где важна прозрачность (ключи, токены в .env);
— Протоколы низкого уровня (Wireshark, отладчики).

Важно: Hex чувствителен к регистру только условно. Стандарты обычно предписывают lowercase (a–f), но многие реализации допускают uppercase. При сравнении следует нормализовать регистр.

URL-encoding (Percent-encoding)

URL-encoding — механизм кодирования символов, недопустимых в URL, согласно RFC 3986. Недопустимыми считаются:
— управляющие символы (0x00–0x1F, 0x7F);
— зарезервированные символы (:, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, =), если они используются не по назначению;
— символы вне ASCII (например, кириллица).

Каждый такой символ заменяется на % и два шестнадцатеричных символа, представляющих его байтовое значение в кодировке UTF-8 (рекомендовано) или другой (например, Windows-1251 — устаревшее, но встречающееся).

Примеры:
— Пробел → %20 (или + в application/x-www-form-urlencoded);
— Кириллическая «Я» в UTF-8 → байты D0 AF → %D0%AF;
— Символ # → %23.

Сложности и подводные камни:
— Разные компоненты URL требуют разного уровня кодирования: домен — Punycode, путь — percent-encoding, параметры — двойное кодирование (если передаются внутри значения другого параметра);
— Неконсистентность между браузерами и серверными фреймворками в обработке + (пробел vs literal +);
— Двойное кодирование: %2520 — это %20, закодированное дважды;
— Атаки на кодирование: %2e%2e%2f → ../, что может использоваться в path traversal.

Рекомендации:
— Всегда использовать UTF-8 при кодировании не-ASCII;
— Избегать ручного конструирования URL — применять встроенные функции (encodeURIComponent в JS, urllib.parse.quote в Python, Uri.EscapeDataString в .NET);
— На сервере — нормализовывать и валидировать пути после декодирования.

Quoted-Printable

Quoted-Printable — схема, используемая в email (MIME, RFC 2045) для кодирования текста, преимущественно ASCII, с минимальными искажениями. Основная идея: оставить читаемыми все печатные ASCII-символы (33–126, кроме =), а остальные представить как =XX, где XX — hex-код байта.

Особенности:
— Мягкий перенос строки: =\r\n в конце строки не входит в данные (используется для соблюдения лимита 76 символов в строке);
— Символ = всегда кодируется как =3D;
— Пробел в конце строки кодируется как =20, иначе может быть удалён транспортными агентами.

Пример:
Привет! в UTF-8 → байты D09F D180 D0B8 D0B2 D0B5 D182 21
→ =D0=9F=D1=80=D0=B8=D0=B2=D0=B5=D1=82!

Применяется, когда текст содержит немного не-ASCII символов и важно сохранить читаемость в plain-text клиентах. Для преимущественно бинарных данных предпочтителен Base64.

Кодирование и Криптография

1. Base64 = шифрование
   Как уже отмечалось, это фундаментальное заблуждение. Base64 обратим без ключа, не скрывает паттерны, не обеспечивает целостности. Пример: токен eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... (JWT) в Base64 легко декодируется в читаемый header и payload. Защита обеспечивается только подписью (HMAC/ECDSA), а не кодированием.

2. Hex-хэш = зашифрованный пароль
   Хранение sha256(password) в базе — серьёзная уязвимость. Хэш не является шифрованием: его нельзя «расшифровать», но можно подобрать (brute-force, rainbow tables). Для паролей требуются KDF с солью (Argon2, scrypt).

3. URL-encoding = защита от XSS/SQLi
   Кодирование полезно для корректного синтаксиса, но не заменяет валидацию и экранирование. Строка %3Cscript%3E после декодирования становится <script> и выполнится, если вставлена в HTML без HTML-escape. Для защиты нужны:
   — input validation (whitelist);
   — output encoding (HTML-escape, SQL-параметры);
   — CSP, prepared statements.

4. Кодирование для «маскировки» API-ключей
   Передача ключа в виде base64("my_secret_key") в заголовке — самоуспокоение. Любой сниффер или лог покажет исходное значение после декодирования. Для аутентификации API следует использовать:
   — bearer-токены с коротким сроком;
   — подписанные запросы (HMAC);
   — OAuth2 с авторизационным сервером.

Практические рекомендации по выбору схемы

Задача	Рекомендуемая схема	Обоснование
Передача бинарных данных в JSON/XML	Base64 (стандартный или URL-safe)	Поддержка во всех парсерах, умеренный overhead
Хранение хэшей, UUID в БД	Hex (lowercase)	Читаемость, простота отладки, отсутствие спецсимволов
Вложения в email (изображения)	Base64	Стандарт MIME, поддержка всеми клиентами
Текст с небольшим количеством не-ASCII	Quoted-Printable	Сохраняет читаемость в plain-text
Параметры в URL	URL-encoding (UTF-8)	Соответствие RFC, безопасность синтаксиса
Экспорт ключей в PEM	Base64 + заголовки	Де-факто стандарт для PKCS#8, X.509

Важно: кодирование не должно применяться рекурсивно. Если данные уже находятся в подходящем формате (например, UTF-8 строка в JSON), дополнительное кодирование избыточно и вредно.

---

Шифрование на практике

Теоретическая стойкость криптографических алгоритмов — необходимое, но недостаточное условие безопасности. Реальная защита достигается только при корректной интеграции шифрования в архитектуру системы, соблюдении операционных процедур и учёте контекста применения. На практике шифрование реализуется на нескольких уровнях стека: от аппаратного (само шифрование в SSD) до прикладного (шифрование полей в JSON). Выбор уровня и инструмента определяется угрозами, требованиями к производительности, совместимости и регуляторным контекстом.

Классификация по области применения

Шифрование на уровне хранилища (Storage Encryption)

Цель — защита данных при физическом доступе к носителю: кража ноутбука, изъятие жёсткого диска, утилизация оборудования. Реализуется двумя основными способами:

1. Прозрачное шифрование дисков (Full Disk Encryption, FDE)
   Весь объём диска (включая системные области, своп, временные файлы) шифруется автоматически на уровне драйвера или контроллера. Пользователь вводит пароль/ключ при загрузке, после чего система работает прозрачно.

   — LUKS (Linux Unified Key Setup) — стандарт де-факто для Linux. Использует dm-crypt (ядро) + LUKS2 (метаданные). Поддерживает:
   • AES-XTS-plain64 (рекомендуется), Serpent, Twofish;
   • PBKDF2, Argon2 для растяжения пароля;
   • несколько ключевых слотов (возможность смены пароля без перезашифровки);
   • внешние ключи (TPM, USB-токен).
   — BitLocker — встроенное решение Windows (Pro/Enterprise/Education). Работает с TPM 1.2+/2.0, поддерживает:
   • AES-CBC (устаревшее) и AES-XTS (рекомендуется);
   • восстановление через Microsoft Account или Active Directory;
   • шифрование съёмных носителей (BitLocker To Go).
   — FileVault — шифрование диска в macOS. Основано на CoreStorage и AES-XTS. Интегрируется с iCloud Recovery Key.

   Преимущества FDE:
   — защита всего содержимого без участия приложений;
   — отсутствие риска утечки через временные файлы, логи, своп.
   Ограничения:
   — не защищает данные при работающей системе (атаки по памяти, зловреды);
   — требует корректной реализации pre-boot аутентификации.

2. Шифрование на уровне устройства (Self-Encrypting Drives, SED)
   Контроллер SSD/HDD выполняет шифрование аппаратно, без нагрузки на CPU. Ключ хранится в защищённой области диска и раскрывается только после аутентификации (пароль, ATA security commands). Поддерживается через OPAL-стандарт и TCG Enterprise.
   — Преимущества: максимальная производительность, защита при сбое питания;
   — Риски: уязвимости в прошивке (например, CVE-2018-2857 в Samsung), отсутствие независимых аудитов.

Шифрование файлов и контейнеров

Применяется, когда требуется защитить отдельные файлы или наборы данных, а не весь диск. Особенно актуально для съёмных носителей, облачных синхронизаций, обмена конфиденциальными документами.

— VeraCrypt — open-source преемник TrueCrypt. Создаёт зашифрованные контейнеры (файлы) или шифрует разделы/диски. Поддерживает:
• Алгоритмы: AES, Serpent, Twofish (в каскаде);
• Режимы: XTS, LRW, CBC с ESSIV;
• Скрытые тома (plausible deniability);
• Противодействие cold boot-атакам (очистка памяти).
Широко используется в средах с повышенными требованиями к конфиденциальности.

— GPG (GNU Privacy Guard) — утилита для шифрования и подписи отдельных файлов по стандарту OpenPGP (RFC 4880). Работает в гибридном режиме:

1. Генерируется случайный сеансовый ключ AES;
2. Данные шифруются этим ключом;
3. Сеансовый ключ шифруется открытым ключом получателя (RSA/ECDSA);
4. Оба компонента объединяются в один файл (.gpg).
   Поддерживает шифрование для нескольких получателей одновременно.

— 7-Zip с AES-256 — архиватор с встроенной поддержкой шифрования имён файлов и содержимого по стандарту ZIP 2.0 (AES). Удобен для обмена, но требует осторожности: слабый пароль легко подбирается.

Шифрование баз данных (Database Encryption)

Цель — защита чувствительных полей (ФИО, паспорта, медицинские данные) от несанкционированного доступа администраторов, при утечке дампов или компрометации сервера СУБД.

Уровни защиты: — TDE (Transparent Data Encryption) — шифрование на уровне страниц/табличных пространств (SQL Server, Oracle, PostgreSQL с расширениями). Прозрачно для приложений, защищает данные на диске, но не в памяти или при передаче.
— Column-level encryption — шифрование отдельных столбцов приложением или триггерами. Требует изменения схемы (тип BYTEA), но даёт гибкость: разные ключи для разных полей, защита даже при компрометации СУБД.
— Application-level encryption — данные шифруются перед отправкой в БД. Максимальная безопасность, но теряются возможности поиска и индексации (требуются специальные схемы — например, encrypted search с tokenization).

Ключевые требования:
— Использование AEAD-режимов (AES-GCM);
— Уникальный nonce/IV на запись;
— Хранение ключей вне СУБД (HSM, KMS);
— Аудит операций с открытыми данными.

Сетевое шифрование (Network Encryption)

Цель — защита данных при передаче по ненадёжным сетям (интернет, Wi-Fi, проводные сегменты с непроверенными узлами).

1. TLS/SSL (Transport Layer Security)
   Стандарт для защищённого соединения «точка-точка» (клиент ↔ сервер). Версия 1.3 (RFC 8446) — текущий стандарт, обеспечивающий:
   — Perfect Forward Secrecy по умолчанию (только (EC)DHE);
   — Удаление небезопасных алгоритмов (RSA key transport, SHA-1, CBC без AEAD);
   — Ускорение handshake (1-RTT, 0-RTT для повторных подключений);
   — AEAD-режимы: AES-GCM, ChaCha20-Poly1305.

   Критически важны настройки:
   — Поддержка современных наборов шифров (TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256);
   — Отключение старых версий (SSL 3.0, TLS 1.0/1.1);
   — Валидация сертификатов (CRL/OCSP, pinning при необходимости);
   — Использование доверенных сертификатов (не самоподписанных в продакшене).

2. IPsec (Internet Protocol Security)
   Шифрование на сетевом уровне (IP-пакеты). Работает в двух режимах:
   — Transport mode — шифруется только payload (для host-to-host);
   — Tunnel mode — инкапсулируется весь IP-пакет (для site-to-site VPN).
   Использует протоколы:
   — IKEv2 (Internet Key Exchange) — для согласования ключей;
   — ESP (Encapsulating Security Payload) — для шифрования и аутентификации.
   Поддерживает AES-GCM, ChaCha20, но настройка сложна; часто заменяется WireGuard.

3. WireGuard
   Современный VPN-протокол, основанный на:
   — Curve25519 для ECDH;
   — ChaCha20-Poly1305 для шифрования и аутентификации;
   — BLAKE2s для хэширования;
   — Noise Protocol Framework для handshake.
   Преимущества:
   — Минималистичный код (~4000 строк ядра);
   — Высокая производительность (часто быстрее IPsec/OpenVPN);
   — Простая конфигурация (публичные ключи в конфиге, без CA);
   — Встроен в ядро Linux с 5.6.
   Ограничения:
   — Отсутствие встроенной аутентификации (требуется внешний механизм — например, скрипты или RADIUS);
   — Динамические IP требуют keepalive.

Стандарты сертификации и соответствие требованиям

Для систем, используемых в госсекторе, финансах, здравоохранении, требуется соответствие международным и национальным стандартам.

FIPS 140-2 и FIPS 140-3 (США)

Federal Information Processing Standard — требования к модулям криптографической защиты. Уровни:
— Level 1 — базовая функциональность (ПО без защиты);
— Level 2 — физическая защита (пломбы, токены);
— Level 3 — защита от извлечения ключа при физическом доступе (HSM);
— Level 4 — устойчивость к атмосферным воздействиям и атакам по побочным каналам.

FIPS 140-3 (2019) заменяет 140-2 и вводит усиленные требования к тестированию и life-cycle management. Сертификация проводится через NIST CAVP.

Common Criteria (ISO/IEC 15408)

Международный стандарт оценки безопасности ИТ-продуктов. Уровни доверия (EAL1–EAL7). Для криптографических модулей обычно требуется EAL4+ (методичное проектирование и тестирование).

ГОСТ и российская сертификация

В РФ применяются:
— ФСТЭК России — сертификация СКЗИ по требованиям «Средства вычислительной техники. Защита от несанкционированного доступа»;
— ФСБ России — сертификация СКЗИ по криптографической стойкости (обязательно для КЭП и систем с ГосСУИ);
— Требования БС2/БС3 — уровни безопасности для АС и ГИС.

Для работы с персональными данными (152-ФЗ) требуется использование сертифицированных СКЗИ при передаче и хранении биометрии, СНИЛС, медицинских данных.

Производительность и компромиссы

Шифрование всегда вносит накладные расходы. Важно оценивать их количественно:

Операция	AES-128-GCM (CPU)	ChaCha20 (CPU)	RSA-2048 (шифр.)	ECDSA P-256 (подпись)
Скорость на современном CPU	3–5 ГБ/с	1–2 ГБ/с	~1 тыс. оп/с	~20 тыс. оп/с
Аппаратное ускорение	AES-NI — +300–500 %	Нет (но выше базовая скорость)	Нет	Частично (Intel QAT)

Рекомендации:
— Для серверов — использовать AES-NI и AES-GCM;
— Для мобильных/IoT — ChaCha20-Poly1305 (выше скорость без инструкций);
— Избегать RSA для согласования ключей — предпочитать (EC)DHE;
— Кэшировать сессионные ключи там, где допустимо (но не нарушать PFS).

Аудит и мониторинг криптографических систем

Эффективность шифрования проверяется тестами и постоянным контролем:

1. Криптографический аудит конфигураций
   — Инструменты: testssl.sh, sslyze, nmap --script ssl-enum-ciphers;
   — Проверка: поддерживаемые версии TLS, алгоритмы, длина ключей, наличие PFS, валидность сертификатов.

2. Мониторинг жизненного цикла ключей
   — Сроки действия сертификатов (автоматические напоминания за 30/15/7 дней);
   — Ротация сеансовых ключей (в идеале — на каждую сессию);
   — Отзыв скомпрометированных ключей (CRL, OCSP Stapling).

3. Логирование операций с ключами
   — Кто и когда использовал/извлек/заменил ключ (особенно в HSM);
   — Попытки доступа с ошибками аутентификации.

4. Тестирование на проникновение
   — Поиск уязвимостей в реализации (side-channel, timing attacks);
   — Проверка обработки ошибок (например, padding oracle в CBC);
   — Атаки на управление ключами (подмена сертификатов, MITM).

Типичные архитектурные ошибки

1. Шифрование без аутентификации
   Использование AES-CBC без HMAC или AES-GCM без проверки тега. Результат — возможность изменения шифротекста с предсказуемым эффектом (bit-flipping attacks).

2. Повторное использование IV/nonce
   В CTR, GCM, ChaCha20 — фатально. Приводит к раскрытию XOR открытых текстов.

3. Хранение ключей в исходном коде или конфигах
   Даже в .env — неприемлемо для продакшена. Использовать:
   — HSM (Hardware Security Module);
   — Облачные KMS (AWS KMS, Azure Key Vault, Yandex Lockbox);
   — Vault-системы (HashiCorp Vault с transit engine).

4. Отсутствие Perfect Forward Secrecy
   Использование статических RSA-ключей для согласования. Компрометация долгосрочного ключа раскрывает всю историю перехваченных сессий.

5. Некорректная обработка ошибок
   Например, возврат разных HTTP-статусов при неверной подписи vs неверном формате — утечка информации для атакующего.

---

Будущее шифрования

Эволюция криптографии не останавливается. С одной стороны, рост вычислительных мощностей, развитие квантовых технологий и усложнение атакующих методик ставят под вопрос стойкость сегодняшних стандартов. С другой — появляются принципиально новые криптографические примитивы, позволяющие решать задачи, считавшиеся невозможными ещё десятилетие назад: вычисления над зашифрованными данными, подтверждение знания без раскрытия содержания, распределённые вычисления без доверия. Ниже рассматриваются ключевые направления, определяющие облик шифрования следующего десятилетия.

Постквантовая криптография (PQC)

Квантовые компьютеры, реализующие алгоритм Шора, способны эффективно решать задачи факторизации и дискретного логарифмирования — математическую основу RSA, DSA, DH и ECC. Это делает все широко используемые асимметричные схемы уязвимыми к атакам с использованием достаточно мощного квантового процессора. Хотя такие устройства пока не достигли необходимого уровня когерентности и числа кубитов (оценки варьируются от 2030 до 2040+ года), переход на постквантовые алгоритмы требует многолетней подготовки: пересмотр протоколов, обновление инфраструктуры, обучение специалистов.

NIST с 2016 года проводит открытый процесс стандартизации PQC. В 2022–2024 годах были объявлены первые стандарты:

Для обмена ключами и шифрования (KEM — Key Encapsulation Mechanism)

— CRYSTALS-Kyber (на основе решёток) — выбран как основной стандарт. Обеспечивает 128-битную стойкость при размере публичного ключа ~800 байт и шифротекста ~768 байт. Эффективен в реализации, устойчив к атакам с утечкой части ключа.
— Classic McEliece (на основе кодов исправления ошибок) — резервный вариант для длительной защиты. Очень стойкий, но с большими размерами ключей (~1 МБ), что ограничивает применение в мобильных системах.

Для цифровых подписей

— CRYSTALS-Dilithium (решётки) — основной стандарт. Баланс стойкости, скорости и размера подписи (~2,5 КБ).
— FALCON (решётки) — для сценариев с жёсткими ограничениями на размер подписи (~500 байт), но сложнее в реализации.
— SPHINCS+ (хэш-функции) — полностью основан на хэшах (SHA-2/SHA-3), что делает его «запасным вариантом» при компрометации других подходов. Подпись велика (~41 КБ), но стойкость минимально зависима от гипотез.

Гибридные схемы

Поскольку сроки появления квантовых угроз неизвестны, а новые алгоритмы ещё не прошли полную проверку в продакшене, рекомендуется использовать гибридные протоколы. Например, в TLS 1.3 можно согласовать общий секрет одновременно через ECDH (X25519) и Kyber. Расшифровка возможна только при компрометации обоих примитивов. Такой подход уже применяется в экспериментальных версиях Cloudflare, Google и Open Quantum Safe (OQS) project.

Важно: симметричное шифрование (AES, ChaCha20) и хэш-функции (SHA-2, SHA-3) не уязвимы к атаке Шора. Алгоритм Гровера позволяет ускорить перебор в √N раз, что компенсируется удвоением длины ключа (AES-128 → AES-256).

Гомоморфное шифрование

Гомоморфное шифрование (HE — Homomorphic Encryption) — класс схем, позволяющих выполнять операции над шифротекстом так, что результат после расшифровки эквивалентен выполнению тех же операций над открытым текстом. Формально:
Dec(K, Eval(E(K, m₁), E(K, m₂))) = m₁ ∘ m₂,
где ∘ — некоторая операция (сложение, умножение).

— Частично гомоморфные схемы (PHE) поддерживают только одну операцию:
• RSA — мультипликативно гомоморфна: E(m₁) · E(m₂) = E(m₁·m₂);
• Paillier — аддитивно гомоморфна: E(m₁) · E(m₂) = E(m₁ + m₂).
Применяются в электронном голосовании, простых агрегациях.

— Полностью гомоморфные схемы (FHE) поддерживают любые вычисления (цепочки сложений и умножений). Первый практический вариант — схема Gentry (2009), реализованная в библиотеках:
• Microsoft SEAL;
• IBM HElib;
• PALISADE;
• OpenFHE.

Основные ограничения FHE:
— Крайне высокая вычислительная сложность (миллионы раз медленнее открытых вычислений);
— Большой «шум», накапливающийся при операциях и требующий периодической «решифровки» (bootstrapping);
— Сложность программирования (специальные DSL, компиляторы).

Практические применения сегодня:
— Медицинская аналитика: исследователь получает зашифрованные данные пациентов, вычисляет статистику, возвращает зашифрованный результат;
— Финансовый скоринг: банк проверяет кредитоспособность клиента, не получая доступ к его исходным данным;
— Облачные вычисления с гарантией конфиденциальности (Confidential Computing — дополняет HE).

Защищённое многопартийное вычисление (MPC — Secure Multi-Party Computation)

MPC позволяет нескольким участникам совместно вычислить функцию f(x₁, x₂, …, xₙ), при этом:
— каждый участник знает только свой вход xᵢ и результат f;
— никто не может восстановить чужие входы.

Принцип работы — разложение данных на «доли» (shares), распределённые между участниками. Операции выполняются над долями локально, с минимальным обменом. Наиболее известные протоколы:
— Garbled Circuits (Yao) — для двух участников;
— Secret Sharing + Beaver Triples (на основе схемы Шамира) — для n участников.

Применения:
— Совместный анализ данных без обмена ими (например, банки оценивают мошеннические паттерны);
— Распределённая генерация ключей (DKG — Distributed Key Generation) для блокчейнов;
— Конфиденциальные аукционы (торги, где ставки скрыты до окончания).

MPC не требует доверенного третьего лица и обеспечивает строгие гарантии даже против коалиции участников, если их число меньше порогового.

Zero-Knowledge Proofs (ZKPs)

Zero-knowledge proof — интерактивный или неинтерактивный протокол, позволяющий одной стороне (доказывающей) убедить другую (проверяющую) в истинности утверждения, не раскрывая никакой дополнительной информации.

Свойства ZKP:
— Полнота — честный доказывающий всегда убедит проверяющего;
— Корректность — мошенник не сможет убедить проверяющего с высокой вероятностью;
— Нулевое разглашение — проверяющий не получает никаких данных, кроме самого факта истинности.

Типы ZKP:

— zk-SNARKs (Succinct Non-interactive ARguments of Knowledge) — компактные, неинтерактивные, требуют доверенной настройки (Trusted Setup). Используются в Zcash, Ethereum (zk-Rollups).
— zk-STARKs (Scalable Transparent ARguments of Knowledge) — не требуют доверенной настройки, масштабируемы, но больше по размеру. Применяются в StarkNet, Polygon Miden.
— Bulletproofs — без доверенной настройки, эффективны для интервалов и диапазонных доказательств. Используются в Monero, Confidential Transactions.

Применения:
— Конфиденциальные транзакции — доказательство корректности платежа без раскрытия суммы и адресов;
— Анонимная аутентификация — пользователь доказывает принадлежность к группе (например, «старше 18»), не раскрывая личность;
— Верификация вычислений — проверка корректности работы удалённого сервера без раскрытия входных данных.

Современные вызовы и угрозы

Криптоанализ и практические атаки

— Side-channel атаки — эксплуатация физических побочных эффектов:
• Timing attacks — анализ времени выполнения операций (например, различие в обработке правильного/неправильного padding);
• Power analysis — измерение энергопотребления чипа (дифференциальный анализ — DPA);
• Electromagnetic analysis — перехват излучения (ван Эйка для CRT, но актуально и для современных SoC).
Защита: константное время выполнения, маскировка, шум.

— Атаки на реализации
• Bleichenbacher’s attack (1998, актуальна до сих пор) — на PKCS#1 v1.5 в RSA;
• Lucky Thirteen — на CBC в TLS с некорректным padding oracle;
• ROBOT — возврат уязвимостей Bleichenbacher в 2017 году в популярных библиотеках.
Вывод: даже доказанно стойкие алгоритмы уязвимы при плохой реализации.

Регуляторное давление и «ослабление шифрования»

Ряд государств (США, Великобритания, Австралия, Россия) выступают за введение обязательных бэкдоров или механизмов «законного доступа» к зашифрованным данным. Предлагаемые меры:
— Key escrow — хранение ключей у государства;
— Client-side scanning — сканирование контента до шифрования (например, в мессенджерах);
— Ограничение длины ключей (как в 1990-х с экспортом криптографии из США).

Такие инициативы разрушают модель безопасности: бэкдор, доступный «только для закона», технически неотличим от уязвимости для злоумышленников. Криптографическое сообщество единодушно против подобных мер (см. позиции IETF, ACM, IEEE).

Экономика и экология шифрования

— Рост вычислительной сложности (PQC, FHE, ZKPs) ведёт к увеличению энергопотребления. Например, подпись Dilithium требует в 10–100 раз больше CPU-циклов, чем Ed25519.
— Необходимость баланса между безопасностью и доступностью: IoT-устройства с ограниченными ресурсами не смогут использовать Kyber без аппаратной поддержки.
— Появление «крипто-оптимизированных» чипов (Apple Secure Enclave, Intel SGX/TDX, ARM TrustZone) как ответа на эти вызовы.

Методологические принципы построения устойчивых систем

На основе накопленного опыта сформулированы ключевые принципы, обеспечивающие долгосрочную криптостойкость:

1. Принцип минимализма
   Использовать минимально необходимый набор алгоритмов и параметров. Чем больше вариантов — тем выше риск неправильной конфигурации. Пример: TLS 1.3 удалил 75 % шифронаборов по сравнению с 1.2.

2. Принцип обновляемости
   Система должна допускать замену алгоритмов без переразработки архитектуры. Пример: гибридные KEM в TLS, поддержка нескольких алгоритмов подписи в X.509.

3. Принцип аудируемости
   Использовать только открытые, прошедшие публичный криптоанализ алгоритмы (AES, SHA-3, Ed25519). Избегать «security through obscurity».

4. Принцип разделения ответственности
   Не полагаться на один примитив. Комбинировать шифрование, аутентификацию, подпись, контроль целостности в многоуровневой защите.

5. Принцип «безопасность по умолчанию»
   Настройки должны быть безопасными из коробки: PFS включён, слабые алгоритмы отключены, сертификаты самопроверяются.

6. Принцип прозрачности управления ключами
   Чётко документировать жизненный цикл ключей: генерация, хранение, ротация, отзыв, уничтожение. Автоматизировать процессы, где возможно.

---